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Abstract 


Currently, there does not exist a simple and dynamic mechanism for 
routers running IS-IS to learn about symbolic hostnames. This 
document defines a new TLV which allows the IS-IS routers to flood 
their name to system ID mapping information across the IS-IS network. 


1. Introduction 


IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a 
node in the network. For management and operation reasons, network 
operators need to check the status of IS-IS adjacencies, entries in 
the routing table and the content of the IS-IS link state database. 
It is obvious that, when looking at diagnostics information, 
hexadecimal representations of systemIDs and LSP identifiers are less 
clear than symbolic names. 


One way to overcome this problem is to define a name-to-systemID 
mapping on a router. This mapping can be used bidirectionally. E.g., 
to find symbolic names for systemIDs, and to find systemIDs for 
symbolic names. One way to build this table of mappings is by static 
definitions. Among network administrators who use IS-IS as their IGP 
it is current practice to define such static mappings. 


Thus every router has to maintain a table with mappings between 


router names and systemIDs. These tables need to contain all names 
and systemIDs of all routers in the network. 
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There are several ways one could build such a table. One is via 
static configurations. Another scheme that could be implemented is 
via DNS lookups. In this document we propose a third solution. We 
hope the proposed solution is easier and more manageable than static 
mapping or DNS schemes. 


2. Possible solutions 


The obvious drawback of static configuration of mappings is the issue 
of scalability and maintainability. The network operators have to 
maintain the name tables. They have to maintain an entry in the table 
for every router in the network. They have to maintain this table on 
each router in the network. The effort to create and maintain these 
static tables grows with the total number of routers on the network. 
Changing the name or systemID of one router, or adding one new router 
introduced will affect the configurations of all the other routers on 
the network. This will make it very likely that those static tables 
are outdated. 


Having one table that can be updated in a centralized place would be 
helpful. One could imagine using the DNS system for this. A drawback 
is that during the time of network problems, the response time of DNS 
services might not be satisfactory or the DNS services might not even 
be available. Another possible drawback might be the added complexity 
of DNS. Also, some DNS implementations might not support A and PTR 
records for CLNS NSAPs. 


A third way to build dynamic mappings would be to use the transport 
mechanism of the routing protocol itself to advertise symbolic names 
in IS-IS link-state PDU. This document defines a new TLV which allows 
the IS-IS routers to include the name to systemID mapping information 
in their LSPs. This will allow simple and reliable transport of name 
mapping information across the IS-IS network. 


3. The Dynamic Hostname TLV 
The Dynamic hostname TLV is defined here as TLV type 137. 
LENGTH - total length of the value field. 
VALUE - a string of 1 to 255 bytes. 
The Dynamic hostname TLV is optional. This TLV may be present in any 
fragment of a non-pseudo node LSP. The value field identifies the 
symbolic name of the router originating the LSP. This symbolic name 


can be the FQDN for the router, it can be a subset of the FQDN or any 
string operators want to use for the router. The use of FQDN ora 
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subset of it is strongly recommended. The content of this value is a 
domain name, see RFC 2181. The string is not null-terminated. The 
systemID of this router can be derived from the LSP identifier. 


If this TLV is present in a pseudo node LSP, then it should not be 
interpreted as the DNS hostname of the router. 


4. Implementation 


The Dynamic Hostname TLV is optional. When originating an LSP, a 
router may decide to include this TLV in its LSP. Upon receipt of an 
LSP with the dynamic hostname TLV, a router may decide to ignore this 
TLV, or to install the symbolic name and systemID in its hostname 
mapping table. 


A router may also optionally insert this TLV in it’s pseudo node LSP 
for the association of a symbolic name to a local LAN. 


5. Security Considerations 
This document raises no new security issues for IS-IS. However, it is 
encouraged to use authentications for IS-IS routing protocol. The 
authentication mechanism for IS-IS protocol is specified in [1] and 
it is being enhanced within IETF in [2]. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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